<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Strict//EN">
<html>

<head>
<meta http-equiv="Content-Language" content="en-us">
<title>Designing dynamic simulations</title>
<link rel="stylesheet" type="text/css" href="../style.css">
</head>

<body>

<div align="center">
<table class=allEncompassingTable >
 <tr>
  <td >
<p><a href="../index.html" TARGET="_top"><img src="images/homeImg.png"></a></p>



<h1>Designing dynamic simulations</h1>

<p>In CoppeliaSim, only a limited number of <a href="objects.htm">objects</a> will be dynamically simulated. Those are <a href="shapes.htm">shapes</a>, <a href="joints.htm">joints</a> and <a href="forceSensors.htm">force sensors</a>, but it will depend on the <a href="scenes.htm">scene</a> structure and object properties, whether a given object will be dynamically simulated. Dynamically simulated objects can be easily recognized during <a href="simulation.htm">simulation</a>, since following icon will appear next to the object's name in the <a href="userInterface.htm#SceneHierarchy">scene hierarchy</a>:<br>
</p>


<p align=center><img src="images/dynamicsDesign1.jpg"></p>
<p class=imageLabel>[Icon marking dynamically simulated objects]</p>
<br>

<p>Double-clicking the icon in the scene hierarchy (during simulation only) will display some information related to the object's dynamic behavior. Objects that are supposed to by dynamically simulated but which, for a reason or another cannot be dynamically simulated, will display following icon instead:<br>
</p>


<p align=center><img src="images/dynamicsDesign2.jpg"></p>
<p class=imageLabel>[Warning icon when an object cannot be dynamically simulated]</p>
<br>
<br>


<table class=subsectionTable><tr class=subsectionTd>
  <td class=subsectionTd>
<a name="staticAndRespondable"></a>Static/non-static,  respondable/non-respondable shapes
</td></tr></table> 

<p>
<a href="shapes.htm">Shapes</a> can be classified into 4 groups depending on their behavior during dynamic simulation: </p>


<p align=center><img src="images/dynamicsDesign3.jpg"></p>
<p class=imageLabel>[Dynamic simulation main shape types]</p>
<br>

<p>During dynamic simulation, static shapes will not be influenced (i.e. their position relative to their parent object is fixed), whereas non-static shapes will be directly influenced by gravity or other constraints (e.g. dynamically enabled joints, see hereafter). Respondable shapes influence each other during dynamic collision (i.e. they produce a mutual <em>collision reaction</em>, they will bounce off each other). Following figure illustrates the static/non-static, respondable/non-respondable behaviors:<br>
</p>


<p align=center><img src="images/dynamicsDesign4.jpg"></p>
<p class=imageLabel>[Static/non-static, respondable/non-respondable shape behaviors and interactions]</p>
<br>

<p>Two respondable shapes will always produce a collision reaction, unless their respective collision masks don't overlap. Static/non-static, respondable/non-respondable shape properties, as well as collision masks can be set in the <a href="shapeDynamicsProperties.htm">shape dynamics properties</a> dialog.<br>
</p>

<br>
<br>

<table class=subsectionTable><tr class=subsectionTd>
  <td class=subsectionTd>
<a name="dynamicallyEnabled"></a>Dynamically enabled joints/force sensors
</td></tr></table> 


<p>Non-static shapes will fall (i.e. be influenced by gravity) if they are not otherwise constrained. Dynamic constraints between shapes can be set-up by attaching two shapes together with a <em>dynamically enabled</em> <a href="joints.htm">joint</a> or with a <em>dynamically enabled</em> <a href="forceSensors.htm">force sensor</a>. <br>
</p>

<li><strong><a name="dynamicallyEnabledJoints"></a>Dynamically enabled joints</strong> are joints that are in force or torque mode or that operate in hybrid fashion (see the <a href="jointProperties.htm">joint properties</a>), and that have a shape as parent object and exactly one child object which must be a non-static shape.  In addition, it is possible to involve a joint in a <em>loop closure configuration</em>. In that case the joint has to connect to the two shapes through a <a href="dummies.htm">dummy</a>-dummy link (where the link type has to be <strong>Dynamics, overlap constraint</strong>). For dummy-dummy links, refer to the <a href="dummyPropertiesDialog.htm">dummy properties</a>.<br>
</li>

<li><strong><a name="dynamicallyEnabledForceSensors"></a>Dynamically enabled force sensors</strong> are force sensors that have a shape as parent object and exactly one child object which must be a non-static shape.  In addition, it is possible to involve a force sensor in a <em>loop closure configuration</em>. In that case the force sensor has to connect to the two shapes through a <a href="dummies.htm">dummy</a>-dummy link (where the link type has to be <strong>Dynamics, overlap constraint</strong>). For dummy-dummy links, refer to the <a href="dummyPropertiesDialog.htm">dummy properties</a>.<br>
</li>

<p>Following figure shows the valid situations where a joint or force sensor is considered to be dynamically enabled (given that the joint/force sensor and the two shapes are located in a <a href="models.htm">model</a> that is dynamically simulated, which is the default case):<br>
</p>

<p align=center><img src="images/dynamicsDesign5.jpg"></p>
<p class=imageLabel>[Valid <em>dynamically enabled joint</em> or <em>dynamically enabled force sensor</em> situations]</p>
<br>

<p align=center><img src="images/dynamicsDesign6.jpg"></p>
<p class=imageLabel>[Example of valid <em>dynamically enabled joint</em> situations]</p>
<br>

<p>It is very important that you follow above guidelines in order to obtain dynamically enabled joints or force sensors. During simulation, if CoppeliaSim discovers force sensors that are not dynamically enabled, it will display a small warning icon next to its name in the scene <a href="userInterface.htm#SceneHierarchy">hierarchy view</a>. The same happens to joints in force/torque mode or that are supposed to operate in a hybrid fashion, and that are not dynamically enabled.<br>
</p>

<p>Following are a few example situations where a joint won't be dynamically enabled:<br>
</p>

<li>
the joint is not in force or torque mode, and the joint is not operating in a hybrid fashion.
</li>

<li>
the joint's parent is not a shape.
</li>

<li>
the joint has more than one child object.
</li>

<li>
the joint directly connects to another joint.
</li>

<li>the joint (or one of the two shapes it connects) is located in a <a href="models.htm">model</a> (hierarchy tree) that is not dynamically simulated (refer to the <a href="modelDialog.htm">model dialog</a> to learn more about how to disable dynamic simulation for a specific model).</li>

<p>Following are a few example situations where a force sensor won't be dynamically enabled:<br>
</p>


<li>
the force sensor's parent is not a shape.
</li>

<li>
the force sensor has more than one child object.
</li>

<li>the force sensor (or one of the two shapes it connects) is located in a <a href="models.htm">model</a> (hierarchy tree) that is not dynamically simulated (refer to the <a href="modelDialog.htm">model dialog</a> to learn more about how to disable dynamic simulation for a specific model).</li>

<br>
<br>
<table class=subsectionTable><tr class=subsectionTd>
  <td class=subsectionTd>
<a name="rigidCompounds"></a>Rigid compounds
</td></tr></table> 

<p>Two non-static <a href="shapes.htm">shapes</a> that are not linked through dynamically enabled joints or force sensors will move independently from each other during dynamic simulation. If you want two or more shapes to behave as one single shape, you will have to group them (Menu Bar --&gt; Edit --&gt; Grouping/Merging --&gt; Group selected shapes). Make sure you adjust the moment of inertia of the final shape appropriately. Make sure you also read the <a href="#pureShapes">section about pure shapes</a> further down:<br>
</p>


<p align=center><img src="images/dynamicsDesign7.jpg"></p>
<p class=imageLabel>[Compound of several non-static shapes to obtain a single non-static shape]</p>
<br>

<p>Compound shapes will behave as a rigid entity and also share identical dynamic properties (e.g. friction coefficient). Sometimes a rigid entity with differentiated dynamic properties is needed. In that case, shapes will have to be rigidly linked via a force sensor. The rigidity of that construction is not as strong as a compound shape, but works well for most cases:</p>

<p align=center><img src="images/forceSensorRigidLink.jpg"></p>
<p class=imageLabel>[Rigid link between two shapes]</p>
<br>

<p align=center><img src="images/forceSensorLinkExample.jpg"></p>
<p class=imageLabel>[Example of a rigid link between two shapes]</p>
<br>


<p>A similar result can be obtained by having  two shapes  linked via two linked dummies. The link type of the two dummies has to be <strong>Dynamics, overlap constraint</strong> (refer to the <a href="dummyPropertiesDialog.htm">dummy properties</a>). During dynamic simulation, the two linked dummies will try to adopt an identical position and orientation. Following figure shows valid rigid loop closure constraints for dynamic simulation:<br>
</p>

<p align=center><img src="images/dynamicsDesign8.jpg"></p>
<p class=imageLabel>[Valid rigid loop closure constraints]</p>
<br>

<p align=center><img src="images/dynamicsDesign9.jpg"></p>
<p class=imageLabel>[Example of valid rigid loop closure constraint]</p>
<br>



<table class=subsectionTable><tr class=subsectionTd>
  <td class=subsectionTd>
<a name="pureShapes"></a>Design consideration 1</td></tr></table> 

<p><strong>Use pure shapes. </strong>Whenever possible, try using <a href="shapes.htm">pure shapes</a> as respondable shapes: pure shapes are much more stable and faster during dynamic simulation. Instead of using the complicated triangular mesh of a robot model as respondable shape, or its slightly better convex representation, try approximating the triangular mesh with several pure shapes, then grouping them [Menu bar --&gt; Edit --&gt; Grouping/Merging --&gt; Group selected shapes] (beware that if you merge pure shapes instead of grouping them, the resulting shape will not be a pure shape anymore). Following figure illustrates a robot's hidden respondable pure shapes:<br>
</p>

<p align=center><img src="images/dynamicsDesign10.jpg"></p>
<p class=imageLabel>[Dynamic robot model (left) and underlying pure non-static shapes used for dynamic simulation (right)]</p>
<br>

<p>A convenient way to extract pure shapes from complex non-pure shapes, is to enter the <a href="triangleEditMode.htm">triangle edit mode</a> for the complex shape, then selecting regions of interest and extracting rectangular, spherical or cylindrical pure shapes. Refer to the <strong>Extract cuboid</strong>, <strong>Extract cylinder</strong>, and <strong>Extract sphere</strong> buttons in the triangle edit mode. Make sure you also read the <a href="rigidBodyTutorial.htm">tutorial on importing and preparing rigid bodies</a>. It is also always good practice to visualize and verify a scene's dynamic content using the dynamic content visualization toolbar button (see the <a href="#dynamicContentVisualization">design consideration 3</a>). </p>
<p>When a body can collide, but not constantly, or does not play a important role in the stability of a mechanism/robot, then it is not absolutely necessary to use pure shapes, and convex shapes could be a viable alternative too:</p>
<br>



<table class=subsectionTable><tr class=subsectionTd>
  <td class=subsectionTd>
<a name="convexShapes"></a>Design consideration 2
</td></tr></table> 


<p><strong>Use convex shapes instead of random shapes. </strong>Whenever possible, try using <a href="shapes.htm">pure shapes</a> as respondable shapes (see <a href="#pureShapes">design consideration 1</a>). This is however not always easy to do, or practical (think of a torus for instance). In that case, you can generate a convex shape, or a convex decomposed shape (i.e. a simple/compound shape containing only convex meshes). Convex shapes perform faster and are more stable than random shapes (but they are still not as fast and stable as pure shapes!).</p>
<p>Select the shapes you wish to simplify as convex shapes, then select [Menu bar --&gt; Edit --&gt; Morph selected shapes into convex shapes...].  Refer also to the item [Menu bar --&gt; Add --&gt; Convex decomposition of selected shapes...]. Following figure illustrates a convex decomposition:<br>
</p>

<p align=center><img src="images/dynamicsDesign15.jpg"></p>
<p class=imageLabel>[Non-convex model (left) and corresponding convex-decomposed model (right)]</p>
<br>




<table class=subsectionTable><tr class=subsectionTd>
  <td class=subsectionTd>
<a name="dynamicContentVisualization"></a>Design consideration 3
</td></tr></table> 


<p><strong>Carefully inspect the dynamic content of a scene</strong>. It can sometimes be a little bit confusing to work with hidden shapes meant to play an active role in the simulation. This is often the case with dynamically enabled shapes, joints or force sensors: indeed, they are most of the time hidden to the viewer's eye. The dynamic content can however always be inspected DURING a simulation, by activating the dynamic content visualization button: </p>

<p align=center><img src="images/dynamicContentButton.jpg"></p>
<p class=imageLabel>[Dynamic content visualization button]</p>
<br>

<p align=center><img src="images/dynamicContent.jpg"></p>
<p class=imageLabel>[Normal and "dynamic content" scene visualization]</p>
<br>

<p>Dynamic objects will appear in various colors, depending on their function or settings. Refer to following figure:
</p>

<p align=center><img src="images/dynamicContentColors.jpg"></p>
<p class=imageLabel>[Color coding for dynamic objects (in dynamic content visualization mode)]</p>
<br>

<p>Notice in above's figure the appearance of non-pure shapes: they have their triangular mesh contour represented in green or grey color. Dynamically simulated non-pure shapes should be avoided at all cost, since they require much longer calculation times, and present a not very stable behaviour (convex shapes are however faster and more stable than non-convex shapes). Refer also to the <a href="#pureShapes">design consideration 1</a> here above. </p>


<br>




<table class=subsectionTable><tr class=subsectionTd>
  <td class=subsectionTd>
<a name="hierarchy"></a>Design consideration 4
</td></tr></table> 


<p><strong>Use a simple hierarchical structure</strong>. When building a model that is meant to be simulated dynamically, attach all non-dynamic objects to the dynamic objects (non-static shapes and dynamically enabled joints). Above's wheeled robot model is illustrated in following figure:<br>
</p>

<p align=center><img src="images/dynamicsDesign11.jpg"></p>
<p class=imageLabel>[Dynamic elements in a robot model]</p>
<br>


<br>



<table class=subsectionTable><tr class=subsectionTd>
  <td class=subsectionTd>
<a name="modelBaseSelection"></a>Design consideration 5
</td></tr></table> 


<p><strong>Carefully chose the model base object</strong>. When building a dynamic <a href="models.htm">model</a>, actually also when building a static model, always carefulls consider what role the model will be playing. Will it be used on its own? Can it be built on top of another model or object? Or can it accept other models or objects to be built on top of it? Consider following example:</p>
<p>You have created a model of a mobile robot. You have also created a model of a gripper. Clearly you want to be able to easily attach the gripper model on top of the robot model. The other way round will never make sense (attaching the robot model on top of the gripper model). You might also want to use the robot model and the gripper model on their own. Following is the view of the <a href="userInterface.htm#SceneHierarchy">scene hierarchy</a> of a possible model definition:</p>

<p align=center><img src="images/dynamicsDesign12.jpg"></p>
<p class=imageLabel>[Example model definition of a robot and a gripper]</p>
<br>

<p>
Notice the model icon next to the 'robot' and 'gripper' shape objects. This indicates that all objects built on top of them are part of the same model definition. The two models operate well on their own. However if you try to attach the gripper on top of the robot (by selecting the gripper model, then the robot model, then clicking [Menu bar --&gt; Edit --&gt; Make last selected object parent]), the gripper will not be staying fixed on the robot during simulation. Following is the scene hierarchy of above two models, where the gripper has been attached to the robot:
</p>

<p align=center><img src="images/dynamicsDesign13.jpg"></p>
<p class=imageLabel>[Non-functional robot-gripper model assembly]</p>
<br>

<p>
Notice in above scene hierarchy how the <a href="shapes.htm">pure shape</a> &quot;gripper&quot; is built on top of the pure shape &quot;robot&quot;. And remember that non-static shapes will fall if not otherwise constrained by a <a href="joints.htm">joint</a> of <a href="forceSensors.htm">force sensor</a>... exactly, we need a force sensor in-between &quot;gripper&quot; and &quot;robot&quot; in order to have a rigid connection between both!</p>
<p>The correct model definition of the robot would have to include an attachment point (or several of them) for the gripper as illustrated in following figure:</p>

<p align=center><img src="images/dynamicsDesign14.jpg"></p>
<p class=imageLabel>[Example model definition of a robot with an attachment point]</p>
<br>

<p>
The attachment point is a simple force sensor. Assembling the gripper model with the robot model above  results in a gripper that stays fixed relative to the robot:</p>

<p align=center><img src="images/dynamicsDesign14b.jpg"></p>
<p class=imageLabel>[Functional robot-gripper model assembly]</p>
<br>


<p> To simplify the assembly procedure even more, you can customize the behaviour of the <a href="userInterface.htm#toolbars"><em>assembling</em> toolbar button</a>, in order to automatically put the gripper onto the attachment point, with the correct relative position/orientation. For further details refer to the <a href="models.htm">section on models</a> and the dialog item <strong>Assembling</strong> in the <a href="commonPropertiesDialog.htm">object common properties</a>.</p>
<br>


<table class=subsectionTable><tr class=subsectionTd>
  <td class=subsectionTd>
<a name="sizes"></a>Design consideration 6
</td></tr></table> 


<p><strong>Use reasonable sizes</strong>. Shapes that are very long and thin, or that are too small might behave strangely (jittering, jumping). Try keeping sizes above 3 centimeters if possible. Otherwise you can adjust the internal scaling parameter in the <a href="dynamicsEngineDialog.htm">dynamics engines general properties</a> dialog.<br>
</p>
<br>

<table class=subsectionTable><tr class=subsectionTd>
  <td class=subsectionTd>
<a name="masses"></a>Design consideration 7
</td></tr></table> 

<p><strong>Keep masses similar and not too light</strong>. When linking two shapes with a dynamically enabled joint or a dynamically enabled force sensor, make sure the two shape's masses are not too different (m1&lt;10*m2 and m2&lt;10*m1), otherwise the joint or force sensor might be very <em>soft</em> and <em>wobbly</em> and present large positional/orientational errors (this effect can however also be used as a <em>natural damping</em> sometimes). Additionally, very low mass shapes should be avoided since they won't be able to exert very large forces onto other shapes (even if propelled by high force actuators!).<br>
</p>
<br>

<table class=subsectionTable><tr class=subsectionTd>
  <td class=subsectionTd>
<a name="inertias"></a>Design consideration 8
</td></tr></table> 


<p><strong>Keep principal moments of inertia* relatively large</strong>. Try keeping the <em>principal moments of inertia / mass</em> (*refer to the <a href="shapeDynamicsProperties.htm">shape dynamics properties</a> dialog) relatively large, otherwise mechanical chains might be difficult to control and/or might behave in a strange way.<br>
</p>
<br>

<table class=subsectionTable><tr class=subsectionTd>
  <td class=subsectionTd>
<a name="layers"></a>Design consideration 9
</td></tr></table> 

<p><strong>Assign dynamic shapes to layer 9</strong>. Assign all dynamic shapes which are supposed to be hidden to layer 9 (refer to the <a href="commonPropertiesDialog.htm">object common properties</a>): in CoppeliaSim, by default, all layers are visible, except for layers 9-16. When editing or testing a <a href="scenes.htm">scene</a>, you can then quickly visualize all hidden  shapes in the scene by temporarily enabling layer 9 (refer also to the <a href="layerSelectionDialog.htm">layer selection dialog</a>).<br>
</p>
<br>


<table class=subsectionTable><tr class=subsectionTd>
  <td class=subsectionTd>
<a name="dynamicStaticDynamic"></a>Design consideration 10
</td></tr></table> 

<p><strong>Never have a static shape between two dynamic items</strong>. The static shape will interrupt the logical behaviour of the dynamic chain:</p>
<p align=center><img src="images/dynamicsDesign16.jpg"></p>
<p class=imageLabel>[Wrong and correct construction]</p>
<br>

<table class=subsectionTable><tr class=subsectionTd>
  <td class=subsectionTd>
<a name="dynamicStaticRespondable"></a>Design consideration 11
</td></tr></table> 

<p><strong>Never have a static respondable shape on top of a dynamic item</strong>. Static means the shape's trajectory cannot be influenced by any collision, but if at the same time it is respondable, this means that it can itself influence other shapes' trajectories via collision. The simulation result would be unpredictable.<br>
</p>




<br>
<h3 class=recommendedTopics>Recommended topics</h3>
<li><a href="dynamicsModule.htm">Dynamics</a></li>
<li><a href="dynamicsDialog.htm">General dynamics properties</a></li>
<li><a href="models.htm">Models</a></li>
<br>
<br>
 </tr>
</table> 
</div>  
  
  
</body>

</html>
